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Abstract 


In this paper, we study the phenomenon that instruction sequences 
are split into fragments which somehow produce a joint behaviour. In 
order to bring this phenomenon better into the picture, we formalize 
a simple mechanism by which several instruction sequence fragments 
can produce a joint behaviour. We also show that, even in the case of 
this simple mechanism, it is a non-trivial matter to explain by means 
of a translation into a single instruction sequence what takes place on 
execution of a collection of instruction sequence fragments. 
Keywords: Fragmented instruction sequence execution, polyadic in- 
struction sequence, program algebra, basic thread algebra. 


1 Introduction 


With the work presented in this paper, we carry on a line of research with 
which a start was made in [4]. This line of research is concerned with 
sequential programs that take the form of instruction sequences. Its working 
hypothesis is that instruction sequence is a central notion of computer science, 
which merits investigation for its own sake. 

An instruction sequence is considered to produce on execution a be- 
haviour to be controlled by some execution environment. This behaviour 
proceeds by performing steps in a sequential fashion. Each step performed 
actuates the processing of an instruction by the execution environment in 
question. A reply returned by this execution environment at completion of 
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the processing of the instruction determines how the behaviour proceeds 
further. 


The following phenomenon presents itself: instruction sequences are 
split into fragments which somehow produce a joint behaviour. The objective 
of this paper is to bring this phenomenon better into the picture. To achieve 
this, we formalize a simple mechanism by which several instruction sequence 
fragments can produce a joint behaviour. We show that, even in the case of 
this simple mechanism, it is a non-trivial matter to explain by means of a 
translation into a single instruction sequence what takes place on execution 
of a collection of instruction sequence fragments. 


The question is how a joint behaviour of the fragments in a collection 
of fragments is achieved. The view of this matter is that there can only be a 
single fragment being executed at any stage, but the fragment in question 
may make any fragment in the collection the one being executed by means 
of a special instruction for switching over execution to another fragment. 
This does not fit in very well with the conception that the collection of 
fragments constitutes a sequential program. To our knowledge, a theoretical 
understanding of this matter has not yet been developed. This has motivated 
us to take up this topic. 


The principal reason for splitting instruction sequences into fragments is 
that the execution environment at hand sets bounds to the size of instruction 
sequences. In the past, the phenomenon occurred explicitly in many software 
systems. At present, it often occurs rather implicitly, e.g. on execution of 
programs written in contemporary object-oriented programming languages, 
such as Java [1] and C# [11], classes are loaded as they are needed. The 
mechanisms in question are improvements upon the simple mechanism 
considered in this paper, but they are also much more complicated. We 
believe that it is useful to consider the simple mechanism prior to the more 
complicated ones. 


The instruction sequences taken for fragments are called polyadic instruc- 
tion sequences in this paper. We introduce polyadic instruction sequences in 
the setting of program algebra [4]. The starting-point of program algebra is 
the perception of a program as a single-pass instruction sequence, i.e. a finite 
or infinite sequence of instructions of which each instruction is executed at 
most once and can be dropped after it has been executed or jumped over. 
This perception is simple, appealing, and links up with practice. 


The behaviours produced by instruction sequences on execution are 
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modelled by threads as considered in basic thread algebra [4].2 We take the 
view that the possible joint behaviours produced by polyadic instruction 
sequences on execution are threads as considered in basic thread algebra 
as well. In a system that provides an execution environment for polyadic 
instruction sequences, a polyadic instruction sequence must be loaded in order 
to become the one being executed. Hence, making a polyadic instruction 
sequence the one being executed can be looked upon as loading it for 
execution. 


In [4], a hierarchy of program notations rooted in program algebra is 
presented. Included in this hierarchy are very simple program notations which 
are close to existing assembly languages up to and including simple program 
notations that support structured programming by offering a rendering of 
conditional and loop constructs. All of these program notations are referred 
to in this paper, but only one of them is actually used. That program 
notation is introduced under the name PGLD in [4]. 


This paper is organized as follows. First, we review basic thread algebra 
and program algebra (Sections 2 and 3). After that, we give an overall 
picture of the hierarchy of program notations rooted in program algebra 
and present the program notation PGLD (Sections 4 and 5). Next, we 
introduce polyadic instruction sequences in the setting of program algebra, 
explain the possible joint behaviours of a collection of polyadic instruction 
sequences using basic thread algebra, and give an example of the use of 
polyadic instruction sequences (Sections 6 and 7). Following this, we extend 
basic thread algebra to allow for threads to make use of services and give a 
description of instruction register file services (Sections 8 and 9). After that, 
we show that, for each possible joint behaviour of a collection of polyadic 
instruction sequences, a single instruction sequence can be synthesized from 
the collection of polyadic instruction sequences that produces on execution 
essentially the behaviour in question by making use of an instruction reg- 
ister file service (Section 10). Finally, we make some concluding remarks 
(Section 11). 


In this paper, we only give brief summaries of program algebra and 
basic thread algebra. Comprehensive introductions, including examples, can 
be found in [4, 14]. 


In [4], basic thread algebra is introduced under the name basic polarized process 
algebra. 
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2 Basic Thread Algebra 


In this section, we review BTA (Basic Thread Algebra). BTA is a form 
of process algebra which is concerned with the behaviour that sequential 
programs produce on execution. Those behaviours are called threads. 

In BTA, it is assumed that fixed but arbitrary finite sets A and Z with 
ANZ = and tau € Z have been given. The members of A are called basic 
actions and the members of Z are called internal actions. The members of 
AUT are referred to as actions. In previous work, we take in essence the 
singleton set {tau} for Z. The generalization made here permits internal 
actions with differences relevant for analysis to be distinguished. 

The operational intuition is that a thread has an execution environment 
which processes each action performed by the thread. A thread performs 
actions in a sequential fashion. Upon each action performed, a reply from 
the execution environment of the thread determines how it proceeds. The 
possible replies are T and F. Performing an internal action, always leads to 
the reply T. 

Although BTA is one-sorted, we make this sort explicit. The reason for 
this is that we will extend BTA with an additional sort in Section 8. 

BTA has one sort: the sort T of threads. To build terms of sort T, BTA 
has the following constants and operators: 


e the inaction constant D: T; 
e the termination constant S: T; 


e for each a € AUZ, the binary postconditional composition operator 
_dab_:TxT—-T. 


We assume that there are infinitely many variables of sort T, including 
x,y,z. Terms of sort T are built as usual (see e.g. [15, 16]). We use infix 
notation for the postconditional composition operator. We introduce basic 
action prefizing as an abbreviation: ao p abbreviates p Jal p. 

The thread denoted by a closed term of the form p dal q will first 
perform a, and then proceed as the thread denoted by p if the reply from the 
execution environment is T and proceed as the thread denoted by q if the 
reply from the execution environment is F. The threads denoted by D and 
S will become inactive and terminate successfully, respectively. A thread 
is inactive if it is neither capable of performing any action nor capable of 
terminating successfully. 
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Table 1: Axiom of BTA 
xadiuby=a dba T1 


Table 2: Axioms for guarded recursion 
(X|E) =(tx|E) if X=tx € E RDP 
E => X=(X|E) ifX€V(E) RSP 


BTA has only one axiom. This axiom is given in Table 1. In this table, 
. stands for an arbitrary member of 7. 

Notice that each closed BTA term denotes a thread that will become 
inactive or terminate after it has performed finitely many actions. Infinite 
threads can be described by guarded recursion. 

A guarded recursive specification over BTA is a set of recursion equations 
E={X =tx | X € V}, where V is a set of variables of sort T and each 
tx is a BTA term of the form D, S or tal?’ with t and ¢’ that contain 
only variables from V. We write V(£) for the set of all variables that occur 
in E. We are only interested in models of BTA in which guarded recursive 
specifications have unique solutions, such as the projective limit model of 
BTA presented in [2]. A thread that is the solution of a finite guarded 
recursive specification over BTA is called a finite-state thread. 

For each guarded recursive specification E and each X € V(E), we 
introduce a constant (X|E) of sort T standing for the unique solution of EF 
for X. The axioms for these constants are given in Table 2. In this table, 
we write (tx|F) for tx with, for all Y € V(£), all occurrences of Y in tx 
replaced by (Y|E). X, tx and E stand for an arbitrary variable of sort 
T, an arbitrary BTA term of sort T and an arbitrary guarded recursive 
specification over BTA, respectively. Side conditions are added to restrict 
what X,tx and & stand for. RDP and RSP are abbreviations for Recursive 
Definition Principle and Recursive Specification Principle, respectively. The 
equations (X|E) = (tx|F) for a fixed E express that the constants (X|F) 
make up a solution of EF and the conditional equations E > X = (X|EF) 
express that this solution is the only one. 

We will use the following abbreviation: a”, where a € AUT, abbreviates 
(X|{X =ao X}). 

We will write BTA+REC for BTA extended with the constants for 
solutions of guarded recursive specifications and axioms RDP and RSP. 
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Table 3: Approximation induction principle 


NO er eee 
mo(x) =D PO 
T+1(S) =$ Pl 
Tn4+1(D) = D p2 
Troi(@ Jab y) = tp(x) dab amy) P3 


Closed terms of sort T from the language of BTA+REC that denote the 
same infinite thread cannot always be proved equal by means of the axioms 
of BTA+REC. We introduce AIP (Approximation Induction Principle) to 
remedy this. AIP is based on the view that two threads are identical if their 
approximations up to any finite depth are identical. The approximation 
up to depth n of a thread is obtained by cutting it off after performing a 
sequence of actions of length n. In AIP, the approximation up to depth n 
is phrased in terms of the unary projection operator 7,:T — T. AIP and 
the axioms for the projection operators are given in Table 3. In this table, a 
stands for an arbitrary member of AU Z. 

We will write BTA+REC+AIP for BTA+REC extended with the 
projection operators and the axioms from Table 3. 


3 Program Algebra 


In this section, we review PGA (ProGram Algebra). The perception of a 
program as a single-pass instruction sequence is the starting-point of PGA. 
In PGA, it is assumed that a fixed but arbitrary set 2 of basic in- 
structions has been given. The intuition is that the execution of a basic 
instruction may modify a state and produces a reply at its completion. The 
possible replies are the Boolean values T and F. The set 2 is the basis for 
the set of all instructions of which the instruction sequences considered in 
PGA are made up. These instructions are called primitive instructions. 
PGA has the following primitive instructions: 


e for each a € 2, a plain basic instruction a; 
e for each a € 2, a positive test instruction +a; 


e for each a € 2, a negative test instruction —a; 
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e for each 1 EN, a forward jump instruction #1; 
e a termination instruction !. 


We write 3 for the set of all primitive instructions. Notice that we use the 
term plain basic instruction to refer to a basic instruction as a primitive 
instruction of a certain kind. 

On execution of an instruction sequence, the effect of a positive test 
instruction +a is that basic instruction a is executed and execution proceeds 
with the next primitive instruction if T is produced and otherwise the next 
primitive instruction is skipped and execution proceeds with the primitive 
instruction following the skipped one. If there is no primitive instruction 
to proceed with, inaction occurs. The effect of a negative test instruction 
—a is the same as the effect of +a, but with the role of the value produced 
reversed. The effect of a plain basic instruction a is the same as the effect 
of +a, but execution always proceeds as if T is produced. The effect of a 
forward jump instruction #1 is that execution proceeds with the /-th next 
primitive instruction of the instruction sequence concerned. If / equals 0 
or there is no primitive instructions to proceed with, inaction occurs. The 
effect of the termination instruction ! is that execution terminates. 

PGA has the following constants and operators: 


e for each u € J, an instruction constant u; 
e the binary concatenation operator _ ;_; 
e the unary repetition operator _”. 


We assume that there are infinitely many variables, including x, y, z. Terms 
are built as usual. We use infix notation for the concatenation operator and 
postfix notation for the repetition operator. 

A closed PGA term is considered to denote a non-empty, finite or 
periodic infinite sequence of primitive instructions.? Closed PGA terms are 
considered equal if they denote the same instruction sequence. The axioms 
for instruction sequence equivalence are given in Table 4. In this table, 
n stands for an arbitrary natural number greater than 0. For each PGA 
term P, the term P” is defined by induction on n as follows: P! = P and 
Prt! — P; P”, The equation XY = X ; X” is derivable. Each closed PGA 
term is derivably equal to one of the form P or P; Q”, where P and Q are 
closed PGA terms in which the repetition operator does not occur. 


3. An infinite sequence is periodic if the set of all its subsequences is finite. 
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Table 4: Axioms of PGA 
(c;y);z=2;(y;z) PGA 
(2)? =a" PGA2 
sy= a” PGA3 
z;y)* =a; (y;z)* PGA4 


Table 5: Defining equations for thread extraction operation of PGA 


a) =aoD #1) =D 
a;2|=ao|a| #0;2|=D 
+a|=a0D #1; = [al 
+a;2|=|z|dab|#2;2| |#l+2;ul=D 
—a|=aoD #1+2;u;2|=|#1+1;2| 
—a;2|=|#2;2|deb>|z| |i|/=s 

!;a|=S 


Each closed PGA term P is considered to denote an instruction sequence 
of which the behaviour is a finite-state thread, called the thread produced 
by P. The set 2 of basic instructions is taken for the set A of basic actions. 
The thread extraction operation |_| determines, for each closed PGA term 
P, a finite guarded recursive specification over BTA that defines the thread 
produced by P. The thread extraction operation is defined by the equations 
given in Table 5 (for a € &, 1 € N and u € J) and the rule that |#/;2| =D 
if #1 is the beginning of an infinite chain of forward jumps. This rule is 
formalized in e.g. [7]. 


The behaviour of each closed PGA term, is a thread that is definable by 
a finite guarded recursive specification over BTA. The other way round, each 
finite guarded recursive specification over BTA in which no internal actions 
occur can be translated into a closed PGA term of which the behaviour is 
the solution of the finite guarded recursive specification concerned. 


Closed PGA terms are considered to denote programs and therefore 
they constitute an elementary program notation. Closed PGA terms are 
also called PGA programs. 
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4 A Hierarchy of Program Notations Rooted in 
Program Algebra 


In [4], a hierarchy of program notations rooted in PGA is presented. The 
program notations that appear in this hierarchy are PGA, PGLA, PGLB, 
PGLC, PGLD, PGLDg, PGLE, and PGLS. The most interesting ones are 
PGLC, PGLD and PGLS. PGLC and PGLD are close to existing assembly 
languages. The main difference between them is that PGLC has relative jump 
instructions and PGLD has absolute jump instructions. PGLS supports 
structured programming by offering a rendering of conditional and loop 
constructs instead of (unstructured) jump instructions. 

For each of the program notations that appear in the hierarchy, except 
PGA, a function is given in [4] by means of which each program from that 
program notation is translated into a program from the first program notation 
lower in the hierarchy that produces the same behaviour on execution. These 
functions are called projections. Moreover, for each of the program notations 
that appear in the hierarchy, except PGLE and PGLS, a function is given 
in [4] by means of which each program from that program notation is 
translated into a program from the first program notation higher in the 
hierarchy that produces the same behaviour on execution. These functions 
are called embeddings. There does not exist a function by which each 
PGLE program is translated into a PGLS program that produces the same 
behaviour on execution because PGLS is strictly weaker than PGLE. The 
names of the projections and embeddings referred to above are given in 
Figure 1. 


The program notations, projections, and embeddings referred to above 
are defined in [4]. We refrain from giving all the definitions in question in this 
paper as well, because most details of the program notations, projections, 
and embeddings do not matter here. The important point is that there 
exist a collection of well-defined program notations rooted in an elementary 
program notation with projections and embeddings between them. Only 
PGLD is actually used later on in this paper. Therefore, PGLD is reviewed 
below in Section 5. 

In Section 6, we will take special versions of the above-mentioned 
program notations for the ones that may be used for fragments. Moreover, 
we will make use of the projections pgla2pga and in addition the projections 
pglb2pga, pglc2pga, ... defined in the obvious way by composition of 
projections given in [4]. In Section 10, we will make use of the embedding 
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PGLS 

pgls2pgle {| 
PGLE 

pgle2pgldg | 7+ pgldg2pgile 
PGLDeg 

pgldg2pgld | + pgld2pgidg 
PGLD 

pgld2pgic | ft pglc2pgid 
PGLC 

pglc2pg1b | fT pglb2pgic 
PGL 

pglb2pgla | ft pgla2pglb 
PGLA 

pgla2pga J pga2pgla 
PGA 


Figure 1: Hierarchy of program notations rooted in PGA 


pglc2pgid and in addition the embedding pga2pgic defined in the obvious 


way by composition of embeddings given in [4]. 


5 The Program Notation PGLD 


In this section, we review the program notation PGLD. This program 


notation is reviewed because it will be used later on in 


Sections 7 and 10. 


In PGLD, like in PGA, it is assumed that there is a fixed but arbitrary 
finite set 2( of basic instructions. Again, the intuition is that the execution 


of a basic instruction a produces either T or F at its co 
PGLD has the following primitive instructions: 


e for each a € 2, a plain basic instruction a; 

e for each a € 2, a positive test instruction +a; 

e for each a € 2, a negative test instruction —a; 

e for each 1 € N, an absolute jump instruction ##1. 


PGLD programs have the form uj;...; ug, where uy, 
instructions of PGLD. 


mpletion. 


...,Uz are primitive 
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The plain basic instructions, the positive test instructions, and the 
negative test instructions are as in PGA. The effect of an absolute jump 
instruction ##I is that execution proceeds with the /-th instruction of the 
program concerned. If ##1 is itself the /-th instruction, then ##I/ results in 
inaction. If / equals O or / is greater than the length of the program, then 
termination occurs. 

The function pgld2pga from the set of all PGLD programs to the set 
of all PGA programs, which translates each PGLD program into a PGA 
program that produces the same behaviour on execution, can be defined 
directly as follows: 


pgld2pga(uy ;...; ux) = (Wir) 3... 5 We(ue) $5)”, 


where the auxiliary functions 7; from the set of all primitive instructions of 
PGLD to the set of all primitive instructions of PGA are defined as follows 
(l<j<hk): 


wj (Hl) = #l-J ifisl<k, 
wj(#H#l) = #kK+2—-(G—-Nif0<l<j, 
(HHL) =! ifl=OVI>k, 
( 


vj(u) =u if wu is not a jump instruction . 


The idea is that each backward jump can be replaced by a forward jump 
if the entire program is repeated. To enforce termination of the program 
after execution of its last instruction if the last instruction is a plain basic 
instruction, a positive test instruction or a negative test instruction, !;! is 


appended to w1(u1) ;---; Ye(ue). 


6 Polyadic Instruction Sequences 


In this section, we formalize a simple mechanism by which several instruc- 
tion sequence fragments can produce a joint behaviour. The instruction 
sequence fragments are viewed as instruction sequences that contain special 
instructions for switching over execution from one fragment to another. The 
instruction sequences in question are called polyadic instruction sequences. It 
is assumed that a special version of PGLA, PGLB, PGLC, PGLD, PGLDg, 
PGLE or PGLS, in which the special instructions for switching over execu- 
tion from one fragment to another are available, is used for each polyadic 
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instruction sequence. Moreover, it is assumed that a collection of polyadic 
instruction sequences between which execution can be switched takes the 
form of a sequence, called a polyadic instruction sequence vector, in which 
each polyadic instruction sequence is coupled with the program notation 
used for it. 

Our general view on the way of achieving a joint behaviour of the 
polyadic instruction sequences in a polyadic instruction sequence vector is 
as follows: 


e there can only be a single polyadic instruction sequence being executed 
at any stage; 


e the polyadic instruction sequence in question may make any polyadic 
instruction sequence in the vector the one being executed; 


e making another polyadic instruction sequence the one being executed is 
effected by executing a special instruction for switching over execution; 


e any polyadic instruction sequence can be taken for the one being 
executed initially. 


In addition to special instructions for switching over execution, polyadic 
instruction sequences may contain two other kinds of special instructions: 


e special instructions for putting instructions into instruction registers; 


e special instructions of which the occurrences in a polyadic instruction 
sequence are replaced by instructions contained in instruction registers 
on making the polyadic instruction sequence the one being executed. 


The special instructions of the latter kind serve as instruction place-holders. 
Their presence turns a polyadic instruction sequence into a parameterized 
instruction sequence of which the parameters are filled in each time it is 
made the one being executed. This feature accounts for the use of the prefix 
polyadic. Its merit is primarily that it allows for execution to proceed in 
effect from different positions each time a polyadic instruction sequence is 
loaded for execution. An example of this is given in Section 7. 

We take the line that different program notations can be used for 
different polyadic instruction sequences in a polyadic instruction sequence 
vector. On making a polyadic instruction sequence in the vector the one 
being executed, it is considered to be translated into a PGA, program. 
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PGA, is a variant of PGA in which the above-mentioned special in- 
structions are incorporated. In PGAp, it is assumed that there is a fixed but 
arbitrary finite set 2l, of core basic instructions. In PGA,, a basic instruction 
is either a core basic instruction or a supplementary basic instruction. 

PGA, has the following core primitive instructions: 


e for each a € &., a plain basic instruction a; 

e for each a € X., a positive test instruction +a; 
e for each a € A, a negative test instruction —a; 
e for each 1 € N, a forward jump instruction #1; 
e a termination instruction !. 


We write 3, for the set of all core primitive instructions. The core primitive 
instructions of PGA, are the counterparts of the primitive instructions of 
PGA. 


PGA, has the following supplementary basic instructions: 
e for each i € N, a switch-over instruction ###1; 
e for each i € N and u € %, a put instruction $put:i:u; 
e for each i € N, a get instruction $get:i. 


We write 2, for the set of all supplementary basic instructions. In the 
presence of a polyadic instruction sequence vector, a switch-over instruction 
##+#1 is the instruction for switching over execution to the i-th polyadic in- 
struction sequence in the vector. A put instruction $put:i:u is the instruction 
for putting instruction u in the instruction register with number 7. A get 
instruction $get:i is the instruction of which each occurrence in a polyadic 
instruction sequence is replaced by the contents of the instruction register 
with number 7 on switching over execution to that polyadic instruction 
sequence. If a get instruction is encountered in the polyadic instruction 
sequence being executed, inaction occurs. 

The supplementary basic instructions of PGA, can be viewed as built- 
in basic instructions. However, as laid down below, supplementary basic 
instructions do not occur in positive or negative test instructions. Thus, the 
core primitive instructions and supplementary basic instructions make up 
the primitive instructions of PGA). 

PGAy, has the following constants and operators: 
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e for each u € J. U As, an instruction constant wu; 
e the binary concatenation operator _ ;_; 
e the unary repetition operator _“. 


The axioms of PGA, are the same as the axioms of PGA. 

Suppose that in PGA the restriction is dropped that 2 must be a finite 
set. Then PGA, can be viewed as the specialization of PGA obtained by 
taking the set 2. U 2%; for 2( and excluding terms in which basic instructions 
from 2, occur in positive or negative test instructions. Henceforth, we 
actually drop the restriction that 21 must be a finite set. This simplifies the 
definitions of the different program notations that can be used for polyadic 
instruction sequences and also enables the use of the functions pgla2pga, 
pglb2pga, etcetera for translating programs in those program notations into 
PGA, programs. 

The different program notations that can be used for polyadic instruction 
sequences are PGLA,, PGLBy, PGLC,, PGLD,, PGLDg,, PGLE,, and 
PGLS,. The set of all PGLA, programs is the subset of the set of all PGLA 
programs, taking the set 2%. U 2, for 2, in which the basic instructions 
from 2, do not occur in positive or negative test instructions. The other 
program notations are defined similarly. If the set 21,U 2, is taken for 2, the 
function pgla2pga translates each PGLA, program into a PGA, program 
that produces the same behaviour on execution. Similar remarks apply to 
the other program notations. 

A polyadic instruction sequence is either a PGLA, program, a PGLB, 
program, a PGLCp program, a PGLD» program, a PGLDg,, program, a 
PGLE, program or a PGLS, program. 

A polyadic instruction sequence vector is a sequence of pairs consisting 
of a polyadic instruction sequence and a member of the set {A, B,C, D, Dg, 
E,S} of program notation indices. 

Let a@ be a polyadic instruction sequence vector, let P,,...,P, and 
C1,...,€n be polyadic instruction sequences and program notation indices, 
respectively, such that a = ((Pi,c1)) ~...~ (Pa; ¢n)),* and let i € [1,n]. 
Then we write pg(a,i) and pgn(a,i) for P; and c;, respectively. 


“We write D* for the set of all finite sequences with elements from set D. We use the 
following notation for finite sequences: () for the empty sequence, (d) for the sequence 
having d as sole element, 0 ~ o’ for the concatenation of finite sequences o and o’, and 
len(c) for the length of finite sequence o. 
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Let a be a polyadic instruction sequence vector of length n, and let 
i € [1,n]. Then program notation index pgn(a,7) indicates which program 
notation is used for polyadic instruction sequence pg(a,i). A stands for 
PGLA,, B stands for PGLB,, etcetera. The program notation used is made 
explicit because it cannot always be determined uniquely from the polyadic 
instruction sequence concerned, whereas the behaviour that this polyadic 
instruction sequence produces on execution may be different for each of 
the program notations in question. For example, every PGLC, program is 
a PGLB, program in which no termination instructions occur. If such a 
program leads to termination on execution as a PGLC, program, it leads to 
inaction on execution as a PGLB, program (for details, see [4]). 

Below, we use special notation relating to the program notation indices. 
Let c be a program notation index. Then we write prj, for the projection 
pgla2pga if c= A, the projection pglb2pga if c = B, etcetera. 

The set of instruction registers that contain an instruction and the con- 
tents of each of those registers matter when a polyadic instruction sequence 
is made the one being executed. That makes us introduce the notion of an 
instruction register file state and special notation relating to this notion. 

An instruction register file state is a function 0: I > 3., where I isa 
finite subset of N. 

Let p be a PGA, program and o be an instruction register file state. 
Then we write pia] for p with, for all i € domain(c), all occurrences of $get:i 
in p replaced by a(t). 

Let i,n € N be such that 1 <i <n, let a be a polyadic instruction 
sequence vector of length n, and let o be an instruction register file state. 
Then we write valid(a,i,o) to indicate that instructions of the form $get:7 
do not occur in prj pgn(a,i)(P9(@; ¢)) [a]. 

An obvious choice of the thread extraction operation of PGA, is the 
thread extraction operation of PGA, taking the set 2. U 2, for 2, restricted 
to the set of closed terms of PGA,. This thread extraction operation is 
considered not to be the proper one, because it treats the supplementary 
basic instructions as arbitrary basic instructions and thus disregards the fixed 
effects that they should produce on execution. For example, a switch-over 
instruction #447 would not have the effect that execution is switched over. 
Moreover, this thread extraction operation would require that in BTA the 
restriction is dropped that A must be a finite set. 

As regards the proper thread extraction for PGA), the idea is that 
it yields, for each PGA, program P, a function that determines, for each 
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polyadic instruction sequence vector a, a finite guarded recursive specification 
over BTA that defines the thread that is the joint behaviour of P and the 
polyadic instruction sequences in @ in the case where P is the polyadic 
instruction sequence being executed initially. Because this behaviour depends 
upon the set of instruction registers that contain an instruction and the 
contents of each of those registers, we need a thread extraction operation for 
each instruction register file state. 

In the thread extraction for PGA), it is assumed that gl ¢ Z. The 
internal action gl (generate and load) represents the internal activity involved 
in switching over execution. The internal actions tau and gl are distinguished 
because tau is considered to represent a negligible internal activity, whereas 
gl is considered to represent a substantial internal activity. 

For each instruction register file state 0, we introduce the thread extrac- 
tion operation |_|,. These thread extraction operations are defined by the 
equations given in Table 6 (for a € A, 1,7 EN, ue J, UA, and v € J.) and 
the rule that |#/; X|,(a) = D if #1 is the beginning of an infinite chain of 
forward jumps. 

We can couple nominal indices as labels with some of the polyadic 
instruction sequences in a polyadic instruction sequence vector. This would 
permit the use of alternative switch-over instructions with nominal indices 
instead of ordinal indices, like with the goto instructions from PGLDg. In the 
notational style of [3], the form of those alternative switch-over instructions 


would be ###(?]. 


7 Example 


To illustrate the mechanism formalized in Section 6, we consider in this 
section the splitting of a PGLD program P of 10000 instructions into two 
fragments. 

We write 1;(l) for the number of absolute jump instructions ##l’ with 
l’ > 5000 from position 1 up to position | and v2(l) for the number of absolute 
jump instructions ##l' with l'! < 5000 from position 5001 up to position J. 

The polyadic instruction sequence P’ corresponding to the first half of 
P is obtained from the first half of P as follows: 


e the instruction $get:1 is prefixed to it; 


e each absolute jump instruction ##/ with 1 < 5000 is replaced by the 
absolute jump instructions ##1’, where l/ =1+1,(1) +1; 
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Table 6: Defining equations for thread extraction operations of PGA, 


ala(a) =a0D 

a; 2|(a) = a0 |el¢(a) 

+al¢(a) =a0D 

+4; 2|¢(@) = |lo(a) Jab |#2;2l4(a) 


—@5; 2|o(a) = |#2; [5 (a) Jab |2]o(a) 


#l|,(a) =D 

#0; z|,(a) =D 

#1; 2|(a) = |2|o(a) 
#1+2;u|-(a) =D 
#l+2;u;2\o(a) = |#l +1; 2|,(a) 


(a) =S 

!;a|,(a) =S 

HHH oA) = glo [PTI pgn(a,1)(PI(,*))lollo(@) if l1<i<nA valid(a,i,c) 
###1|-(a) =D if 1<t<nA-7valid(a,i,c) 
#H##i|,(a) =S ift=OVi>n 

HAHi sclo(A) = Bl © [PT yn(a,y(P9(04))[olo(a) if 1 <i < mA valid(a,i,o) 
###i;2\-(a) =D if 1 <i<nA-nvalid(a,i,c) 
#H##Hi;2|-(a) =S ifi=OVi>n 


$put:é:v ; t|>(a@) = tau o |2|,ea40](@) 
$get:7|,(a) =D 
$get:2 ; z|-(a) =D 


e each absolute jump instruction ##/ with | > 5000 is replaced by the 
instruction sequence $put:2:#l’ ; #4¢#2, where I’ = (1 — 5000) + va(1 
5000); 


and the polyadic instruction sequence P” corresponding to the second half 
of P is obtained from the second half of P as follows: 


e the instruction $get:2 is prefixed to it; 
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e each absolute jump instruction ##/ with / > 5000 is replaced by the 
absolute jump instructions ##l’, where l’ = (1—5000) +v2(1—5000) +1; 


e each absolute jump instruction ##/ with 1 < 5000 is replaced by the 
instruction sequence $put:1:#1' ; #7441, where I! =1+1,(I). 


Notice that the positions occurring in jump instructions are adapted to the 
prefixing of a get instruction to each half of P and the replacement of each 
jump instructions that gives rise to a jump into the other half of P by two 
instructions. 

For any instruction register file state 0, we have that |P| coincides with 
|$put:1:41; ###1|,(((P’, D)) ~ ((P"”, D))) after the presence of the internal 
actions tau and gl in the latter behaviour has been concealed. In Section 8, 
we will introduce operators to conceal the presence of internal actions. 

In this section, we have illustrated by means of an example that splitting 
a program into fragments is relatively simple. In Section 10, we will show that 
synthesizing a program from a collection of fragments is fairly complicated. 


8 Threads-Services Interaction and Abstraction 


A thread may make use of services. That is, it may perform certain actions 
for the purpose of having itself affected by a service that takes them as 
commands to be processed. The processing of an action may involve a change 
of state of the service and at completion of the processing of the action the 
service returns a reply value to the thread. The reply value determines how 
the thread proceeds. In this section, we review the use operators, which 
are concerned with threads making such use of services.> We also introduce 
abstraction operators. They serve for concealment of the presence of internal 
actions, which arise among other things from the use operators. Both use 
operators and abstraction operators will be used later on in Section 10. 

It is assumed that a fixed but arbitrary finite set F of foci and a fixed 
but arbitrary finite set M of methods have been given. Each focus plays the 
role of a name of a service provided by the execution environment that can be 
requested to process a command. Each method plays the role of a command 
proper. For the set A of basic actions, we take the set {f.m| f € F,me M}. 
Performing a basic action f.m is taken as making a request to the service 
named f to process command m. 


°This version of the use mechanism was first introduced in [6]. In later papers, it is 
also called thread-service composition. 
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A service H consists of 
e aset S of states; 
e an effect function eff :M x S > S; 
e a yield function yld: M x S > {T,F,B}; 
e an initial state s9 € S; 


satisfying the following condition: 
Ym € M,s € S«(yld(m,s) =B => Vm! € Me yld(m’, eff(m,s)) = B). 


The set S contains the states in which the service may be, and the functions 
eff and yld give, for each method m and state s, the state and reply, 
respectively, that result from processing m in state s. By the condition 
imposed on services, once the service has returned B as reply, it keeps 
returning B as reply. 

Let H = (S, eff, yld, so) be a service and let m € M. Then the derived 
service of H after processing m, written 3H , is the service (5S, eff, yld, 89) 
where sj = eff(m, so); and the reply of H after processing m, written H(m), 
is yld(m, so). 

When a thread makes a request to the service to process m: 


e if H(m) 4B, then the request is accepted, the reply is H(m), and the 
service proceeds as oH : 


e if H(m) =B, then the request is rejected and the service proceeds as 
a service that rejects any request. 


We introduce the sort S of services and, for each f € F, the binary use 
operator _ /f_:T x S + T. The axioms for these operators are given in 
Table 7. In this table, . stands for an arbitrary member of Z, f and g stand 
for arbitrary foci from *, and m stands for an arbitrary method from M. 

Intuitively, p/p H is the thread that results from processing all basic 
actions performed by thread p that are of the form f.m by service H. When 
a basic action of the form f.m performed by thread p is processed by service 
A, it is turned into the internal action tau and postconditional composition is 
removed in favour of action prefixing on the basis of the reply value produced. 
This intuition is covered by axioms TSU5 and TSU6. Axioms TSU3 and 
TSU4 express that internal actions and basic actions of the form g.m with 
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Table 7: Axioms for use operators 


S/yH=S TSUL 
D/;H=D TSU2 
(Loa) /y H =10 (a /; H) TSU3 
(x dg.mb y) /; H=(x/s H) dg.m& (y/; H) if fAG TSU4 
(xi f.mb y) /p H =tauo (x /s 2H) if H(m) =T TSU5 
(xi fmby) /p H =tauo(y/s 3H) if H(m) =F TSU6 
(cdfmby)/pH=D if H(m) =B TSU7 


Table 8: Axioms for abstraction operators 


7,(S) = TT1 
7,(D) =D rr 
T,(L0 x) = 7,(2x) TT3 
T(x Jab y) =7,(2) dab 7,(y) ifaAzAe TT4 
An>o T(tn(®)) = (Any) => T(x) = Ty) aS 


f #4 are not processed. Axiom TSU7 expresses that inaction occurs when 
a basic action to be processed is not accepted. 

Let T stand for either BTA, BTA+REC or BTA+REC+AIP. Then 
we will write T+TSU for T, taking the set {f.m | f € F,m € M} for A, 
extended with the use operators and the axioms from Table 7. 

For each zs € Z, we introduce the unary abstraction operator 7,:T > T 
to conceal the presence of internal action 1 in the case where its presence 
does not matter. The axioms for the abstraction operators are given in 
Table 8. In this table, a stands for an arbitrary action from AU TZ. 

A main difference between the version of the use mechanism introduced 
here and the version of the use mechanism introduced in [10] is that the former 
version does not incorporate abstraction and the latter version incorporates 
abstraction. 

Let T stand for either BTA, BTA+REC, BTA+REC+AIP, BTA+TSU, 
BTA+REC+TSU or BTA+REC+AIP+TSU. Then we write T+ABSTR 
for T extended with the abstraction operators and the axioms from Table 8. 

For each v € Z, the equation 7,(c”) = D is derivable from the axioms of 
BTA+REC+AIP+ABSTR. 
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9 Instruction Register File Services 


In this section, we describe services that make up register files with a finite 
set of registers that can contain instructions from a finite set of core primitive 
instructions. These services will be used in Section 10. 

It is assumed that a fixed but arbitrary set J C N such that J = [1,n] for 
some n € N and a fixed but arbitrary finite set U C 3. have been given. The 
set I is considered to contain the positions of the registers in the instruction 
register file and the set U is considered to contain the instructions that can 
be put in those registers. 

We write IRFS for the set U,c,;1' > U. The members of [RFS are 
considered to be the possible instruction register file states. It is assumed 
that a fixed but arbitrary bijection 0: IRFS — [1,card(JRFS)] has been 
given. 


The instruction register file services accept the following methods: 
e for each i € J and u€ U, a register put method put:i:u; 
e for each j € range(0), a register file test method eq:j. 


We write Mi for the set {put:i:u | ie TA ue U}U {eq:j | 7 € range(0)}. 
It is assumed that Mirp C M. 


The methods accepted by instruction register file services can be ex- 
plained as follows: 


e put:i:u: the contents of register 2 becomes instruction u and the reply 
is T; 


e eq:j: if the state of the instruction register file equals 0~'(j), then 
nothing changes and the reply is T; otherwise nothing changes and the 
reply is F. 


Let s € IRFS U {ft}, where t ¢ IRFS. Then the instruction register file 
service with initial state s, written TRF ,, is the service (IRFS, eff, yld, s), 
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where the functions eff and yld are defined as follows (o € IRFS U {t}):® 


eff (put:i:u,0o) =a @lirr ul, yld(put:i:n,o) =T, 

eff (ea:j,0) =o , yld(eq:j,o)=T if Ao) = 5, 
yld(eq:j, 0 2 Fo if OC) FA, 

eff(m,o)=T ifmeMir, — yld(m,o) = ifm € Mir , 

eff(m,t) =t , stan, tT) =B. 


10 Program Synthesis 


In order to establish a connection between collections of instruction sequence 
fragments and instruction sequences, we show in this section that, for each 
possible joint behaviour of a collection of instruction sequence fragments, 
a single instruction sequence can be synthesized from the collection that 
produces on execution essentially the behaviour in question by making use 
of an instruction register file service. More precisely, we show that, for 
each PGA, program P and polyadic instruction sequence vector a, a PGA 
program P’ can be synthesized from P and a such that, for all relevant 
instruction register file states a, |P’| /i¢ ZRF, coincides with |P|,(a) after 
the presence of the internal actions tau and gl has been concealed. 

Let P be a PGA, program and a be a polyadic instruction sequence 
vector. The general idea is that: 


e each polyadic instruction sequence in a is translated into a PGA, 
program and an appropriate finite collection of instances of this PGA, 
program in which occurrences of get instructions are replaced by core 
primitive instructions is generated; 


e P and all the generated programs are translated into PGLC, programs 
and these PGLC, programs are concatenated; 


e the resulting PGLC, program is translated into a PGLD, program 
and this program is translated into a PGLD program by replacing 
all occurrences of the supplementary instructions by core primitive 
instructions as follows: 


®We use the following notation for functions: [] for the empty function; [d+ 7] for 
the function f with domain(f) = {d} such that f(d) =r; and f @ g for the function h 
with domain(h) = domain(f) Udomain(g) such that, for all d € domain(h), h(d) = f(d) if 
d ¢ domain(g) and h(d) = g(d) otherwise. 
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— a switch-over instruction ###i is replaced by an absolute jump 
instruction whose effect is a jump to the beginning of an appended 
instruction sequence whose execution leads, after the state of the 
instruction register file has been found by a linear search, to a 
jump to the beginning of the right instance of the PGA) program 
that corresponds to the ith polyadic instruction sequence in a; 


— a put instruction $put:i:u is simply replaced by the plain basic 
instruction irf.put:i:u; 


— a get instruction $get:i is simply replaced by the absolute jump 
instruction whose effect is a jump to the position of the instruction 
itself. 


A collection of instances of the PGA, program corresponding to a polyadic 
instruction sequence in a is considered appropriate if it includes all instances 
that may become the one being executed. P and all the generated pro- 
grams are translated into PGLC, programs because PGLC, programs are 
relocatable: they can be concatenated without disturbing the meaning of 
jump instructions. The PGLC, program resulting from the concatenation 
is translated into a PGLD, program before the supplementary instructions 
are replaced because the replacement of a switch-over instruction by an 
absolute jump instruction is simpler than its replacement by a relative jump 
instruction. 

Following the general idea outlined above, we will define a function 
pgap2pgl1d that yields, for each PGA, program P, a function that gives, for 
each polyadic instruction sequence vector a, a PGLD program P’ such that, 
for each relevant instruction register file service state o, |pgld2pga(P’)| /ie 
IRF, coincides with |P|,(a) after the presence of the internal actions tau 
and gl has been concealed. 

The function pgap2pgld from the set of all PGA, programs to the set 
all functions from the set of all polyadic instruction sequence vectors to the 
set of all PGLD programs is defined as follows: 


pgap2pgld(x)(a) = 
translate(pglc2pg1d(expand(x)(a))) ; 


+irf.eq:1 ; ##l1;...3 +irfeqin’ ; ##L ny ; 


+irf.eq:1; ##ln1 ;...; +irf-eq:n’; H#lan , 
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where n = len(a), n’ = max(range(6)), the function expand from the set 
of all PGA, programs to the set all functions from the set of all polyadic 
instruction sequence vectors to the set of all PGLCp programs is defined as 
follows: 


expand(x)(a) = 
pga2pglc(x) ; 
pga2pglc(gen(a,1,0~1(1)));...; pga2pgle(gen(a, 1,471 (n’))) ; 
pga2pglc(gen(a,n,O~'(1)));...; pga2pgle(gen(a,n, 9-1 (n’))) , 


where n = len(a), n’ = max(range(@)), and the function gen from the set 
of all polyadic instruction sequence vectors, the set of all natural numbers 
and the set of all instruction register file states to the set of all PGA, 
programs is defined as follows: 


gen(a, a, a) = DT samtaay (pg (a, t)){o] ifl<7< len(q) A valid(a, 1, a) ’ 
gen(a,i,a) = #0 if 1 <i <len(a) A 7Vvalid(a,i,o) , 
gen(a,i,a) =! ifi=O0Vi> len(a), 


the function translate from the set of all PGLD, programs to the set of all 
PGLD programs is defined as follows: 


translate(uy ;...3 Uk) = U1(u1);.-.3 Yi(ur) , 


where the functions w; from the set of all primitive instructions of PGLD, 


to the set of all primitive instructions of PGLD are defined as follows 
(Lt peek): 


0; (##H?) PHL; if l <2 <len(@), 
W(t) =! ifi =OVi>len(a), 
w,;($put:i:u) = irf.put:i:u , 
w;($getz) = ##I, 

i( 


u) =U if wis not a supplementary basic instruction , 


Sy 
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where for each i € [1, len(a)]: 


1; = len(pga2pglc(x)) 


+ S° len(pga2pgle(prj pan(a,n) (Pg(@; h)) [97 (h’)])) 
he[1,len(a)],h’Erange() 


+2-max(range(@)) - (i —1), 


and for each 7 € [1,len(a@)] and 7 € range(6): 


lij = len(pga2pglc(z)) 
+ S- len(pga2pgle (prj pgn(a,n) (Pg(@, h)) [07 (h’)])) 
he€[1,i—1],h’ Erange(6) 


af YS > len(pga2pgl.e( Pry pyn(a,a)(P9(a, 4))[0~"(h’)])) - 
hell ,j—1] 


The following theorem states rigorously that, for any PGA, program P 
and polyadic instruction sequence vector a, for all relevant instruction register 
file states o, |pgld2pga(pgap2pgld(P)(q@))| /i¢ ZRF coincides with |P|,(a) 
after the presence of the internal actions tau and gl has been concealed. 


Theorem 1 Let P be a PGA) program and a be a polyadic instruction 
sequence vector, and let n be the highest number occurring in instruc- 
tions of the form $put:i:u or $get:i in P or a. Take the interval [1,n| 
for I and the set of all core primitive instructions occurring in instruc- 
tions of the form $put:i:u in P or a for U, and let o € IRFS. Then 
Trau (|PEld2pga(pgap2pgld(P)(a))| /ir TRF co) = Ttau(Tei(|Plo(@))). 


Proof: The proof of Theorem 1 follows the same line as the proof of 
Theorem 1 from [8] given in that paper. Here, we give only a brief outline of 
the proof of the current theorem. 

The proof of this theorem proceeds as follows: (i) we give a set T of 
closed terms of sort T with ttau(Tgi(|P|>(a))) € T, a set T’ of closed terms 
of sort T with 7au(|pgld2pga(pgap2pg1d(P)(a))| /ip TRFo) € T’, anda 
bijection 6: T — T"; (ii) we show that there exists a set FE consisting of one 
derivable equation p = p’ for each p € T such that, for all equations p = p’ 
in FE: 


e B(p) = p” is a derivable equation if p” is p’ with, for all q € T, all 
occurrences of g in p’ replaced by 6(q); 
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e p' €T only if p’ can be rewritten to a q’ ¢ T using the equations in E 
from left to right. 


The latter means that tau (|pgld2pga(pgap2pgld(P)(a))| /in ZRF.) and 
Trau(Tgi(|P|>(@))) denote solutions of the same guarded recursive specifi- 
cation. Because guarded recursive specifications have unique solutions, it 
follows immediately that trau(|pgld2pga(pgap2pgl1d(P)(a))| /i¢ ZRFo) = 


Ttau (te1(|P|o(@))). 


In the proof outlined above, an apposite indexing of the closed terms in the 
sets T’ and T” facilitates the definition of the bijection @. Yet, this definition 
is much more complicated than the definition of the bijection needed in the 
proof from [8] referred to. 

The definition of pgap2pgld shows that the synthesis of single instruc- 
tion sequences from collections of instruction sequence fragments is fairly 
complicated. 


11 Conclusions 


We have given a formalization of a simple mechanism by which several 
instruction sequence fragments can produce a joint behaviour. Thread ex- 
traction provides the possible joint behaviours of a collection of instruction 
sequence fragments. We have shown that, for each possible joint behaviour of 
a collection of instruction sequence fragments, a single instruction sequence 
can be synthesized from the collection that produces on execution essen- 
tially the behaviour in question by making use of a service. This program 
synthesis is reminiscent of the service-based variant of projection semantics 
for program notations used in [5]. The program synthesis shows that it is a 
non-trivial matter to explain by means of a translation into a single instruc- 
tion sequence what takes place on execution of a collection of instruction 
sequence fragments. 

In this paper, an instruction sequence fragment in a collection of in- 
struction sequence fragments has two attributes: an ordinal index (position) 
and a program notation index. We have also mentioned that a nominal 
index (label) could be an optional attribute. Many other attributes that are 
relevant in practice can be imagined, e.g. modification date, author, tester, 
owner, user, and security level. In this paper, we have restricted ourselves 
to attributes that are indispensable for a theoretical understanding. 

The question arises whether all aspects of the mechanism formalized 
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in this paper can be dealt with at the level of threads. This issue has been 
investigated in [9]. It happens that not all aspects can be dealt with at the 
level of threads. In particular, the ability to replace special instructions in 
an instruction sequence fragment by different ordinary instructions every 
time execution is switched over to that fragment cannot be dealt with at 
the level of threads. Threads turn out to be too abstract to deal with the 
mechanism in full. 

It is sometimes suggested that program algebra is closely related to 
Kleene algebra [13] and omega algebra [12] — an extension of Kleene al- 
gebra with an infinite iteration operator. In program algebra, programs 
are considered at a more concrete level than in Kleene algebra and omega 
algebra. For instance, Kleene algebra and omega algebra are not concerned 
with instruction sequences, and program algebra is not concerned with 
non-determinism. 
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